THINK C provides a very nice environment for writing device drivers. Unfortunately, they do not tell you how to get them installed and running. This document, and the code provided here, will give some background on the problem and solutions. Refer to the Device Manager chapter of Inside Macintosh for more information.
Device drivers are special pieces of code that the Device Manager is in charge of calling. To keep track of device drivers, the Device Manager keeps a table in the system heap called the unit table, which is just an array of handles. Each handle is a device control entry handle, which is where the Device Manager stores all of the information it needs for each device driver. One field of the device control entry is the handle of the device driver code. (If the device driver is in ROM, then the field is really a pointer to the ROM code.) When the OpenDriver routine is called, it normally reads the driver resource out of the resource file, and then calls the _DrvrInstall trap to create a device control entry and install it into the unit table. (If the driver was already installed in the unit table, OpenDriver just calls the drivers open routine and sets a flag in the device control entry to "open".) OpenDriver uses the resource ID of the driver as the place in the unit table in which to install the driver. For instance, the resource ID for the Sony disk driver is 1, so the device control entry for that driver is in slot 1 of the unit table. This works just fine for the Macintosh OS, but not so great for us folks who want to write our own drivers.
There are 2 problems: (a) The Macintosh OS knows where all of its device drivers are going to be installed before boot time and can number its driver resources appropriately; if you and I write drivers that have the same resource ID, we are going to try and install on top of eachother, which would be bad. (b) The first 48 slots in the driver table are reserved to the Macintosh OS drivers and desk accessories. Unfortunately, on the Macintosh Plus, there are only 48 slots to begin with. The Macintosh SE has only 64 slots, so we might even run out of room there.
The solution to problem (a) is pretty easy. The Macintosh OS is kind enough to make sure that empty slots in the unit table are marked as nil. We can just load up the driver resource ourselves, then look through the unit table for an empty slot and call the _DrvrInstall trap to create the device control entry and install it into the unit table slot that we specify. Then when OpenDriver is called, it will just call the drivers open routine and set the flag. Problem (b) is a little trickier: There is an unreleased Macistosh Technical Note which describes how to increase the size of the unit table, and a good deal of the code in this archive is to do just this.
There is one additional problem for THINK C: THINK C uses resources to hold global data as well as multiple code segments for its device drivers. Of course, THINK C assumes that it can base the resource ID's for these resources on the slot number in the unit table, since the resource ID of the driver is usually the same as the slot number. THINK C uses the "owned resource" scheme documented in the Resource Manager chapter of Inside Macintosh and calls GetResource for these resources every so often when it needs things. But since we will be putting the driver into a random empty slot, the resources will probably be numbered wrong. We could renumber the resources in the resource file, but that assumes (a) that it is not on a read-only volume and (b) that we have not done something nasty like call DetachResource on the driver and closed the resource file (which is quite handy to do for drivers installed into the system heap by INITs).
The solutions to all of the problems presented here are in the source code provided in this archive.
This archive contains 4 source files for use with device drivers. Though the code was written specifically with users of THINK C's device driver facilities in mind, it can be easily used in any development environment. The files "driver.c" and "driver.h" are the real meat of the code: they include the routines "InstallRAMDriver" and "RemoveRAMDriver". These are the routines you will call to install your device driver into the system heap and remove it. There is also the file "drvrincludes.h", which is included by "driver.c" and has compilation options for THINK C 4.0.x, THINK C 5.0.x or MPW 3.x and a definition for a resource ID you must set. The last file, "THINKProc.c", contains code for THINK C users. It should be compiled as a separate code resource which will be loaded and called from within driver.c. The calls to GetResource in the THINK C driver glue are actually replaced with calls to this code. It is needed because of the way THINK C handles global data and multiple code segments for device drivers.
There are no global references anywhere in the code, so you may decide to create a library out of it, for instance by compiling it in a project in THINK C and using it like MacTraps.
All of the code contained in this archive is freely distributable. You may use it in your own code if you like. All that I ask is that you give me credit somewhere.
